The uxTaskGetSystemState needs more consideration. uxTaskGetSystemState also suspends the scheduler.
If a blocked or suspended task is readied by an ISR while the running task suspends the scheduler, the task's state will still be eBlocked or eSuspended with current logic. vTaskList also make use of this information.

The following approach may fix the problem:

• Get the system state in critical section instead of suspending scheduler. This ensures that no task will be added in pending ready list when getting system state.
• Handle tasks already in pending ready separately in uxTaskGetSystemState.

(Edit: Deleted a comment that overlooked the inconsistency between uxTaskGetSystemState() and eTaskGetState(). It seems the inconsistency was introduced in #679.)

Is there a benefit to distinguishing ePendingReady from eReady in the API? The pending-ready status is a scheduler implementation detail not currently exposed to the API. From the user's perspective, maybe a task in the pending-ready list really is eReady.

Reading Jeff's comment, I agree it could be confusing to expose internal implementation detail. The PR is responding to this scenario: #577, so the question is, is that a valid scenario. Is it valid to call eTaskGetState() when the scheduler is suspended when the generalised rule of thumb is not to call API functions from a critical section or with the scheduler suspended.

The head revision already returns eReady for this scenario.

Agreed with Jeff's and Richard's comment. Let's close this PR and create another for minor update with eReady comment.

@chinglee-iot Prior to #679, eTaskGetState() would return eBlocked or eSuspended under the conditions being discussed. After #679, it returns eReady. However, #679 did not make the corresponding change to uxTaskGetSystemState(), which still returns eBlocked or eSuspended. Thus #679 introduced a minor inconsistency. Addressing that inconsistency would probably make a good PR.

In my opinion returning eReady is ideal behavior, even considering that a developer making this API call with the scheduler suspended is suspect, as Richard says. So I think changing uxTaskGetSystemState() to match the current eTaskGetState() behavior is best.

@jefftenney I will create another PR for the uxTaskGetSystemState() function. Let's discuss in the new PR.

We created another PR for uxTaskGetSystemState() function. #702